Is there a reason to handle this in this library? I’m doing the same thing in cssta, but handle the splitting filter variable declarations before handing them off to here (see getStyleDeclarations)

Happy to hear if there’s a reason to do otherwise though!

Is there a reason to handle this in this library?

What I thought was that it's easy to handle here because the values for the custom props will be handled by the parser, e.g.

--my-prop: 56px;

to

"--my-prop": 56

I could of course handle them in the library level, but then that's just unnecessary boilerplate to: first strip out the --, then give it to the parser that turns the prop to camel case, then take the result and turn the prop back to kebab case and add -- in the beginning.

I’m not sure that works. If you did,

--test: 5px;
z-index: var(--test);

This shouldn’t work, but I think in your example it will

@jacobp100 I'm not sure what your point is here. I think that I need to explain what I'm trying to achive. :)

What did previously was to allow various CSS units to be passed through the parser:
#83

With that I was able to add support for CSS viewport units, which are calculated at runtime.

What I want now is to pass custom properties (e.g. --my-prop) through the parser without the property name being modified, but convert the value of the custom property to something that React Native can understand. Doing that does not break the current functionality in any way.

The part where the custom property gets used (e.g.var(--my-prop)) is something that this CSS parser does not need to worry about.

So css-to-react-native will handle the parsing of the properties/values, but the support for CSS Custom properties is implemented elsewhere.

For example I want css-to-react-native to parse this:

--my-prop: 4px;
--other-prop: 4vw;
font-size: var(--other-prop);

to this:

{
  "--my-prop": 4,
  "--other-prop": "4vw",
  fontSize: "var(--other-prop)"
}

That code will just give a warning or throw an error in React Native, but if I have a library between the result from this parser and React Native, the end result can look like this:

{
  fontSize: 15
}

I definitely get what you're trying to do! Maybe a better example of what I'm trying to say could be,

--body-size: 14px;
font: var(--body-size) "Helvetica";

If you removed the px in --body-size, as you proposed, you'd get font: 14 "Helvetica", which would not parse.

This won't just apply to font though. margin, padding etc. all expect units, so they'd crash too!

You are correct that any shorthand values would throw if you use them together with var(). But like I said earlier, css-to-react-native should not have to worry about parsing values with var().

As a workaround I can match the shorthand values in a similar way that css-to-react-native does and use a placeholder value (random number), e.g.

--body-size: 14px;
font: var(--body-size) "Helvetica";

↓ ↓ ↓ ↓ ↓ ↓

--body-size: 14px;
font: 53463023px "Helvetica";

and then just replace 53463023 in the result with the custom prop value 14 or if I want to do some runtime matching I could just replace 53463023 from the parsed value with var(--body-size).

↓ ↓ ↓ ↓ ↓ ↓

{
   "--body-size": 14
   "fontFamily": "Helvetica",
   "fontSize": 53463023,
   "fontStyle": "normal",
   "fontVariant": [],
   "fontWeight": "normal"
}

↓ ↓ ↓ ↓ ↓ ↓

{
   "--body-size": 14
   "fontFamily": "Helvetica",
   "fontSize": "var(--body-size)",
   "fontStyle": "normal",
   "fontVariant": [],
   "fontWeight": "normal"
}

@jacobp100 Now that I'm thinking about this again, maybe it would be better to allow the short hand props to pass both CSS functions and length units through the parser.

I can use the workaround I mentioned, but if I would implement support for any other CSS function (e.g. calc), then my code would be full of boilerplate code to handle the workarounds.

So what if we whitelist the most common CSS functions and make the parser transform this:

--body-size: 14px;
font: var(--body-size) "Helvetica";

into this:

{
   "--body-size": 14
   "fontFamily": "Helvetica",
   "fontSize": "var(--body-size)",
   "fontStyle": "normal",
   "fontVariant": [],
   "fontWeight": "normal"
}

What do you think?

That won't quite work, since CSS vars can contain multiple or complex values.

--font-config: 14px/18px;
font: var(--font-config) "Helvetica";

The expected value for this would be { fontSize: 14, lineHeight: 18, fontFamily: "Helvetica" }. But we have no way to work this out in this library.

Oh I didn't think of that! I guess in that case the only way is to implement the logic in my library

Might be best! The logic gets quite complicated, especially when variables reference other variables!